Skip to content

Conversation

pull[bot]
Copy link

@pull pull bot commented Feb 28, 2020

See Commits and Changes for more details.


Created by pull[bot] (v2.0.0-alpha.3)

Can you help keep this open source service alive? 💖 Please sponsor : )

@pull pull bot added the ⤵️ pull label Feb 28, 2020
@pull pull bot added the merge-conflict Resolve conflicts manually label Mar 27, 2020
HerbertJordan and others added 26 commits June 17, 2025 14:44
Fixes a data race on the `wallets` slice when closing account Manager.

At the moment, there is a data race between a go-routine calling the
Manager's `Close` function and the background go-routine handling most
operations on the `Manager`. The `Manager`'s `wallets` field is accessed
without proper synchronization.

By moving the closing of wallets from the `Close()` function into the
background thread, this issue can be resolved.
fixes the gnark deserialisation

---------

Co-authored-by: Felix Lange <[email protected]>
Adds marshaling fuzzing for G1 and G2 to oss-fuzz. 

Also aligns the behavior of the google library to that of gnark and
cloudflare, which only ever read the first 64 / 128 bytes of the input,
regardless of how long the input is
As #31769 defined a global
hash pool, so we can reuse it, and also remove the unnecessary
KeccakState buffering

---------

Co-authored-by: Gary Rong <[email protected]>
Reading a single transaction out of a block shouldn't need decoding the
entire body

---------

Co-authored-by: Felix Lange <[email protected]>
Co-authored-by: Gary Rong <[email protected]>
Since we have the effective gas price in the message, we can compute tip by
simply subtracting the basefee. No need to recompute the effective price.

---------

Co-authored-by: Felix Lange <[email protected]>
In this pull request, the original `CacheConfig` has been renamed to `BlockChainConfig`.

Over time, more fields have been added to `CacheConfig` to support
blockchain configuration. Such as `ChainHistoryMode`, which clearly extends
beyond just caching concerns.

Additionally, adding new parameters to the blockchain constructor has
become increasingly complicated, since it’s initialized across multiple
places in the codebase. A natural solution is to consolidate these arguments 
into a dedicated configuration struct.

As a result, the existing `CacheConfig` has been redefined as `BlockChainConfig`.
Some parameters, such as `VmConfig`, `TxLookupLimit`, and `ChainOverrides`
have been moved into `BlockChainConfig`. Besides, a few fields in `BlockChainConfig`
were renamed, specifically:

- `TrieCleanNoPrefetch` -> `NoPrefetch`
- `TrieDirtyDisabled` -> `ArchiveMode`

Notably, this change won't affect the command line flags or the toml
configuration file. It's just an internal refactoring and fully backward-compatible.

---------

Co-authored-by: Felix Lange <[email protected]>
The optimization tried to defer allocating the cache map until it was used for the
first time. It's a relic from earlier times, when tries were copied often. This seems
unnecessary now, so we can just create the map when the trie is created.

---------

Co-authored-by: Felix Lange <[email protected]>
Aligns the marshaling behavior of gnark to google and cloudflare

Co-authored-by: kevaundray <[email protected]>
This PR improves the IsOnCurve methods for BN254 G2 points by:

* Clarifying its behavior the docstring, making it explicit that it
verifies both the point being on the curve and in the correct subgroup.

* Adding an in-line comment explaining the subgroup membership check
(c.Mul(Order)).

 * Minor wording adjustments for readability and consistency.
implement #31945

---------

Co-authored-by: prpeh <[email protected]>
Co-authored-by: Gary Rong <[email protected]>
This pull request introduces a mechanism to expose statistics from the
state reader, specifically related to cache utilization during state prefetching.

To improve state access performance, a pair of state readers is constructed 
with a shared local cache. One reader to execute transactions  ahead of time
to warm up the cache. The other reader is used by the actual chain processing 
logic, which can benefit from the prefetched states.

This PR adds visibility into how effective the cache is by exposing relevant 
usage statistics.

---------

Signed-off-by: Csaba Kiraly <[email protected]>
Co-authored-by: Csaba Kiraly <[email protected]>
Improve the prefetcher concurrency allowance.
We need at least one prefetch goroutine. SetLimit(0) would block
prefetch.

Signed-off-by: Csaba Kiraly <[email protected]>
Previously, PathDB used a single buffer to aggregate database writes,
which needed to be flushed atomically. However, flushing large amounts
of data (e.g., 256MB) caused significant overhead, often blocking the
system for around 3 seconds during the flush.

To mitigate this overhead and reduce performance spikes, a double-buffer
mechanism is introduced. When the active buffer fills up, it is marked
as frozen and a background flushing process is triggered. Meanwhile, a
new buffer is allocated for incoming writes, allowing operations to
continue uninterrupted.

This approach reduces system blocking times and provides flexibility in
adjusting buffer parameters for improved performance.
…32067)

If Geth is engaged in a long-run block synchronization, such as a full
syncing over a large number of blocks, invoking `debug_setHead` will
cause `downloader.Cancel` to wait for all fetchers to stop first.
This can be time-consuming, particularly for the block processing
thread.

To address this, we manually call `blockchain.StopInsert` to interrupt
the blocking processing thread and allow it to exit immediately, and
after that call `blockchain.ResumeInsert` to resume the block
downloading process.

Additionally, we add a sanity check for the input block number of
`debug_setHead` to ensure its validity.

---------

Signed-off-by: jsvisa <[email protected]>
Co-authored-by: Gary Rong <[email protected]>
Replaced the outdated and broken link to the Web3 Secret Storage
Definition with the current official URL from ethereum.org in the Clef
README. This ensures users have access to up-to-date and accurate
documentation for the keystore file format.
Implement #32078 
Parse and lookup the delegation account if EIP7702 is enabled.

---------

Signed-off-by: jsvisa <[email protected]>
Downloading from a range was failing because it would return and error
early with an error misinterpreting "start-end".

---------

Co-authored-by: shantichanal <[email protected]>
Co-authored-by: Gary Rong <[email protected]>
rjl493456442 and others added 30 commits August 26, 2025 21:53
This pull request refactors the internal implementation in path database
a bit, specifically:

- purge the state index data in batch
- simplify the logic of state history construction and index, make it more readable
closes #32240 #32232

The main cause for the time out is the slow json encoding of large data.
In #32240 they tried to resolve the issue by reducing the size of the
test. However as Felix pointed out, the test is still kind of confusing.

I've refactored the test so it is more understandable and have reduced
the amount of data needed to be json encoded. I think it is still
important to ensure that the default read limit is not active, so I have
retained one large (~32 MB) test case, but it's at least smaller than
the existing ~64 MB test case.
)

Replace hardcoded 5-second sleep with polling loop that actively checks
snap sync state. This approach is already used in other project tests
(like account_cache_test.go) and provides better reliability by:

- Reducing flaky behavior on slower systems
- Finishing early when sync completes quickly
- Using 1-second timeout with 100ms polling intervals

---------

Co-authored-by: lightclient <[email protected]>
…pics (#32503)

When the log has empty or nil topics, the generated bindings code will
panic when accessing `log.Topics[0]`, add a check to avoid it.
…32347)

This pull request implements #32235 , constructing blob sidecar in new
format (cell proof)
if the Osaka has been activated.

Apart from that, it introduces a pre-conversion step in the blob pool
before adding the txs.
This mechanism is essential for handling the remote **legacy** blob txs
from the network.

One thing is still missing and probably is worthy being highlighted
here: the blobpool may
contain several legacy blob txs before the Osaka and these txs should be
converted once
Osaka is activated. While the `GetBlob` API in blobpool is capable for
generating cell proofs
at the runtime, converting legacy txs at one time is much cheaper
overall.

---------

Co-authored-by: MariusVanDerWijden <[email protected]>
Co-authored-by: lightclient <[email protected]>
Fixes a prestateTracer test case covering 7702 delegation.

---------

Co-authored-by: Jared Wasinger <[email protected]>
Co-authored-by: Sina Mahmoodi <[email protected]>
fix problematic function name in comment

Signed-off-by: slicesequal <[email protected]>
When maxPeers was just above some perfect square, and a few peers
dropped for some reason, we changed the peer selection function.
When new peers were acquired, we changed again.

This PR improves the selection function, in two ways. First, it will always select
sqrt(peers) to broadcast to. Second, the selection now uses siphash with a secret
key, to guard against information leaks about tx source.

---------

Signed-off-by: Csaba Kiraly <[email protected]>
Co-authored-by: Felix Lange <[email protected]>
Add better error context for EIP-6110, EIP-7002, and EIP-7251 processing
in state processor to improve debugging capabilities.
Fix problematic function name in comment.
Do my best to correct them all with a script to avoid spamming PRs.
This pull request preserves the root->ID mappings in the path database
even after the associated state histories are truncated, regardless of
whether the truncation occurs at the head or the tail.

The motivation is to support an additional history type, trienode history. 
Since the root->ID mappings are shared between two history instances, 
they must not be removed by either one.

As a consequence, the root->ID mappings remain in the database even
after the corresponding histories are pruned. While these mappings may 
become  dangling, it is safe and cheap to keep them.

Additionally, this pull request enhances validation during historical
reader construction, ensuring that only canonical historical state will be
served.
`db inspect` on the full database currently takes **30min+**, because
the db iterate was run in one thread, propose to split the key-space to
256 sub range, and assign them to the worker pool to speed up.

After the change, the time of running `db inspect --workers 16` reduced
to **10min**(the keyspace is not evenly distributed).

---------

Signed-off-by: jsvisa <[email protected]>
Co-authored-by: Gary Rong <[email protected]>
### Summary
Fixes long-standing ETA calculation errors in progress indicators that
have been present since February 2021. The current implementation
produces increasingly inaccurate estimates due to integer division
precision loss.

### Problem

https://github.com/ethereum/go-ethereum/blob/3aeccadd04aee2d18bdb77826f86b1ca000d3b67/triedb/pathdb/history_indexer.go#L541-L553
The ETA calculation has two critical issues:
1. **Integer division precision loss**: `speed` is calculated as
`uint64`
2. **Off-by-one**: `speed` uses `+ 1`(2 times) to avoid division by
zero, however it makes mistake in the final calculation

This results in wildly inaccurate time estimates that don't improve as
progress continues.

### Example
Current output during state history indexing:
```
lvl=info msg="Indexing state history" processed=16858580 left=41802252 elapsed=18h22m59.848s eta=11h36m42.252s
```

**Expected calculation:**
- Speed: 16858580 ÷ 66179848ms = 0.255 blocks/ms  
- ETA: 41802252 ÷ 0.255 = ~45.6 hours

**Current buggy calculation:**
- Speed: rounds to 1 block/ms
- ETA: 41802252 ÷ 1 = ~11.6 hours ❌

### Solution
- Created centralized `CalculateETA()` function in common package
- Replaced all 8 duplicate code copies across the codebase

### Testing
Verified accurate ETA calculations during archive node reindexing with
significantly improved time estimates.
Filtering for leaf nodes was missing from #32388, which means that even
the root done was reported, which made little sense for the bloatnet
data processing we want to do.
Implement the binary tree as specified in [eip-7864](https://eips.ethereum.org/EIPS/eip-7864). 

This will gradually replace verkle trees in the codebase. This is only 
running the tests and will not be executed in production, but will help 
me rebase some of my work, so that it doesn't bitrot as much.

---------

Signed-off-by: Guillaume Ballet
Co-authored-by: Parithosh Jayanthi <[email protected]>
Co-authored-by: rjl493456442 <[email protected]>
~Will probably be mostly supplanted by #32224, but this should do for
now for devnet 3.~

Seems like #32224 is going to take some more time, so I have completed
the implementation of eth_config here. It is quite a bit simpler to
implement now that the config hashing was removed.

---------

Co-authored-by: MariusVanDerWijden <[email protected]>
Co-authored-by: Guillaume Ballet <[email protected]>
Co-authored-by: rjl493456442 <[email protected]>
Switches to using counters so that the gauges don't cause any
information to be lost. Counters can be used to calculate all sorts of
metrics on Grafana. Which is also why min/avg/max logic is removed to
make things simple and small here.
This pull request fixes a regression, introduced in #32190

Specifically, in GetBlobsV1 engine API, if any blob is missing, the null
should be placed in
response, unfortunately a behavioral change was introduced in #32190,
returning an error
instead.

What's more, a more comprehensive test suite is added to cover both
`GetBlobsV1` and
`GetBlobsV2` endpoints.
Update all the accumulated changes
Another getBlobs PR on top of
#32190 to avoid some minor
regressions.

- bring back more log messages from before
- continue processing also on some internal errors
- ensure v2 complies with spec even if there are internal errors

---------

Signed-off-by: Csaba Kiraly <[email protected]>
Co-authored-by: rjl493456442 <[email protected]>
#32418)

This PR is the first step in the trienode history series.

It introduces the `nodeWithOrigin` struct in the path database, which tracks
the original values of dirty nodes to support trienode history construction.

Note, the original value is always empty in this PR, so it won't break the 
existing journal for encoding and decoding. The compatibility of journal 
should be handled in the following PR.
As in #32060 we introduced the file based journal path, for the other
sub command(eg: snapshot, db), we should also pass the directory to the
triedb, else the subcommand(eg: `geth snapshot`) failed to run:

```bash
geth snapshot verify-state --datadir /geth-data
...
INFO [09-02|02:12:29.493] Allocated cache and file handles         database=/geth-data/geth/chaindata cache=512.00MiB handles=524,288
INFO [09-02|02:12:32.746] Opened ancient database                  database=/geth-data/geth/chaindata/ancient/chain readonly=true
INFO [09-02|02:12:32.746] Opened Era store                         datadir=/geth-data/geth/chaindata/ancient/chain/era
INFO [09-02|02:12:32.758] State scheme set to already existing     scheme=path
INFO [09-02|02:12:32.760] Load database journal from disk
INFO [09-02|02:12:32.764] Failed to load journal, discard it       err="journal not found"
INFO [09-02|02:12:32.789] Opened ancient database                  database=/geth-data/geth/chaindata/ancient/state readonly=true
INFO [09-02|02:12:32.790] Initialized path database                readonly=true triecache=0.00B statecache=0.00B buffer=0.00B history="entire chain"
ERROR[09-02|02:12:32.791] Failed to verify state                   root=c5458d..4cc785 err="unknown layer: c5458d476da0136a67ef24a93b909aa5c29efa5c5b885dbd1fbaed4e784cc785"
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
⤵️ pull merge-conflict Resolve conflicts manually
Projects
None yet
Development

Successfully merging this pull request may close these issues.